소프트웨어 위탁 개발 전략

2025-11-11, G25DR

1. 소프트웨어 위탁 개발의 전략적 이해

소프트웨어 위탁 개발(아웃소싱)은 더 이상 단순한 비용 절감 수단이 아니다. 이는 기업의 비즈니스 프로세스를 근본적으로 변화시키고 시장의 불확실성에 대한 적응력을 확보하기 위한 핵심 전략이다. 그러나 많은 기업이 이러한 ’전략적 목표’를 추구하면서도, 여전히 ’전통적 방식’인 비용 절감에만 매몰되어 위탁 개발을 관리하는 심각한 모순에 빠진다. 이러한 접근 방식의 불일치, 즉 ’전략적 파트너’에게 ’최저가 입찰’을 요구하는 행위 자체가 프로젝트 실패의 근본 원인이 된다. 이는 필연적으로 낮은 품질의 결과물, 빈번한 분쟁, 그리고 궁극적으로는 초기 예산을 초과하는 ‘비용 증가’ 1로 귀결된다.

따라서 성공적인 위탁 개발의 첫걸음은, 아웃소싱을 단순한 ’용역’이 아닌 ’전략적 파트너십’으로 재정의하는 것에서 시작해야 한다.

1.1 위탁 개발(아웃소싱)의 정의: 비용 절감을 넘어선 전략적 도구

과거 IT 아웃소싱은 기업 내부의 기술력이나 개발 인력이 부족할 때, IT 기능의 전반 혹은 부분적 책임을 외부 업체에 맡기는 것을 의미했다.2 이 시기의 주된 목적은 명확히 ’비용 절감’이었다.2

그러나 IT 기술이 비즈니스의 핵심으로 자리 잡은 현재, 아웃소싱의 정의는 ’IT 발전에 따라 비즈니스 프로세스를 변화시키기 위한 전략’으로 진화했다.2 이는 단순히 IT의 비핵심 기능을 외부에 위탁하는 것을 넘어, 불확실한 시장 상황 변화에 대응하여 비즈니스의 적응력을 확보하고, 전문 분야에 집중하여 고부가가치 업무 형태를 창출하기 위한 능동적인 경영 전략이다.2 이러한 진화는 아웃소싱의 형태를 단순 ITO(IT Outsourcing)에서 BPO(Business Process Outsourcing), 나아가 전사적 변혁을 추구하는 BTO(Business Transformation Outsourcing)로 발전시켰다.2

1.2 핵심 이점: 전문성 확보, 핵심 역량 집중, 비용 예측

위탁 개발을 전략적으로 활용할 때 기업이 얻을 수 있는 핵심 이점은 명확하다.

• 전문 인력 및 기술 활용: 기업이 내부에서 확보하기 힘든 고도의 전문 인력과 최신 기술을 즉각적으로 활용할 수 있다.1 이는 기술 변화의 속도를 따라잡기 어려운 중소기업에 특히 중요하다.
• 핵심 역량 강화: 정보 시스템의 구축 및 운영에 투입되어야 하는 비용과 인력을 기업의 본질적인 핵심 역량(예: 제품 개발, 마케팅, 고객 관리)에 집중적으로 투자할 수 있게 한다.1
• 정확한 비용 예측: 견적 및 계약에 따라 프로젝트 비용을 사전에 정확히 예측할 수 있어, 예산의 효율적인 운용이 가능해진다.1

1.3 내재된 위험: 의존성, 품질 실패, 숨겨진 비용

이러한 이점에도 불구하고, 위탁 개발에는 치명적인 위험이 내재되어 있으며, 이는 이점과 동전의 양면 관계에 있다. 특정 이점을 극대화하려는 시도는 필연적으로 특정 위험을 증폭시킨다.

• 비용 증가 가능성 (숨겨진 비용): ‘비용 절감’ 1을 극단적으로 추구하여 최저가 업체를 선정할 경우, 이는 ‘부정확한 요구사항’ 해석, ‘불리한 계약’, ’빈번한 분쟁’으로 이어진다.1 결국 초기 견적에 없던 추가 비용이 발생하여, 내부에서 직접 운영하는 것보다 오히려 총비용이 증가하는 최악의 결과를 초래할 수 있다.1
• 의존성 문제 (Dependency): ‘전문 인력 활용’ 1을 위해 기업의 핵심 IT 기능까지 모두 위탁할 경우, 해당 벤더(개발사)에 대한 과도한 의존 상태에 빠진다.1 이 상태가 고착화되면, 발주사는 IT 서비스 조달의 유연성과 선택 범위를 상실하며 1, 기술 발전에 뒤처지고 비용 협상력을 잃게 된다.
• 전략 변경 문제 (Reversibility): 벤더에 대한 의존성이 높아지면, 아웃소싱 대상 기능이나 사업자를 변경하려 할 때 막대한 ’교체 비용’이 발생한다.1
• 기타 위험: 이 외에도 외부 팀과의 ‘통신 문제’, ’품질 관리’의 어려움, ‘보안 위험’ 등이 상존한다.3

결론적으로, 성공적인 위탁 개발은 이점을 극대화하는 활동이 아니라, 이점과 위험 사이의 균형점을 찾는 고도의 ‘위험 관리’ 활동이다. ’핵심 기능 및 핵심 인력’은 내부에 유지하면서 1 중장기적 계획에 기반하여 아웃소싱을 추진해야만 내재된 위험을 통제할 수 있다.

2. 아웃소싱 모델의 유형과 선택 기준

프로젝트의 성패를 좌우하는 첫 번째 분기점은 ’어떤 형태’로 계약하고(법률) ’어느 범위’까지 맡길 것인지(전략)를 결정하는 것이다.

2.1 계약 형태에 따른 분류: 도급, 위임, 파견

소프트웨어 개발 위탁 계약은 법적 성격에 따라 크게 세 가지로 분류된다.2

• 도급 (Fixed-Price): 발주자가 ‘일정한 업무 결과’ 즉, ‘성과물’(예: 쇼핑몰 앱 완성)에 대해 보수를 지급하는 계약이다. ’성과물 수반’이 필수적이다.2
• 위임 (Delegation / Time & Material): 발주자가 수탁자(개발사)에게 ‘일정한 업무 처리’ 자체를 위임하는 계약이다 (예: 월 단위 개발 인력 투입). ’성과물 수반’은 법적 필수가 아니다.2
• 파견 (Dispatch): 파견 사업주와 체결된 계약에 따라 파견 기술자가 ‘정해진 업무만’ 수행하는 형태다.2

대부분의 발주사는 명확한 ‘성과물’ 2을 원하기 때문에 ‘도급’ 계약을 선호한다. 하지만 실제 프로젝트 진행 과정에서는 요구사항이 불명확하거나 4 자주 변경되어, ’일정한 업무 처리’를 요구하는 ’위임’처럼 행동하는 경우가 빈번하다. 이러한 불일치는 “계약된 성과물이 아니다“라는 개발사의 방어와 “일하고 있으니 돈을 달라“는 요구로 이어져 심각한 분쟁을 자초한다.

따라서, 명확한 결과물을 원한다면 반드시 ‘도급’ 계약을 체결해야 한다. 하지만 이를 위한 절대적인 전제 조건은, 발주사가 4장에서 설명할 ‘성과물’(요구사항)을 사전에 명확하게 정의하는 것이다.4 불명확한 요구사항을 가지고 ‘도급’ 계약을 체결하는 것이야말로 프로젝트 실패를 보장하는 최악의 시나리오다.

2.2 개발 범위에 따른 전략: 전체(Total) 위탁과 선택적(Selective) 위탁

어디까지 맡길 것인지에 따라 두 가지 상반된 전략이 존재한다.

• 전체(Total) 아웃소싱: IT 기능 전반을 하나의 업체에 맡기는 방식이다.
• 장점: 관리 창구가 ’단일화’되고 ’통합성’이 높으며, 기업은 핵심 부문에 역량을 집중할 수 있다.2
• 단점: 벤더에 대한 ’종속’이 심화되고, 발주사 내부의 ’전문성 결여’를 초래하며, 개발사가 다시 제3자에게 재하청을 줄 가능성이 있다.2
• 선택적(Selective) 아웃소싱: 특정 기능이나 분야(예: 서버 관리, 앱 개발, 데이터 분석)를 각각 전문 업체에 맡기는 방식이다.
• 장점: 각 분야의 최고 ’전문성’을 확보할 수 있고, 기업의 전반적인 ’정보화 수준’이 향상되며, 계약 변경 시 유리하다.2
• 단점: 여러 업체 간 ’조정의 어려움’이 발생하고, 문제 발생 시 ’책임 소재’가 불명확하며, ’기능 통합’이 어려울 수 있다.2

‘전체’ 위탁은 막대한 관리 자원과 강력한 협상력을 가진 대기업에 적합한 모델이다. 자원이 부족한 중소기업이 ‘전체’ 위탁의 편리함이라는 유혹에 빠지면, 1.3절에서 언급한 ‘의존성 문제’ 1에 직결된다. 해당 업체가 곧 중소기업의 IT 부서가 되어버려, 종속으로 인한 비용 협상력 상실과 기술 낙후를 피할 수 없다.

따라서 중소기업의 생존 전략은 ‘선택적’ 위탁이어야 한다. 당장은 ‘조정의 어려움’ 2이 있더라도, 핵심 기능(예: 서비스 기획, 핵심 데이터 소유권)은 반드시 내부에 유지해야 한다. 그리고 비핵심 기능들을 ’선택적’으로 위탁함으로써 2, 벤더 간의 건전한 경쟁을 유도하고 종속의 위험을 분산시켜야 한다.

3. 성공적인 위탁 개발을 위한 전(全) 주기 관리 (SDLC)

소프트웨어 위탁 개발은 ‘계약하고 기다리는’ 과정이 아니다. 발주자는 소프트웨어 개발 생명 주기(SDLC, Software Development Life Cycle)의 전 과정에 걸쳐 ’수동적 관찰자’가 아닌 ’능동적 관리자’가 되어야 한다.

3.1 표준 SDLC 6단계의 이해

SDLC는 소프트웨어를 계획, 설계, 개발, 테스트, 배포, 유지보수하는 전 과정을 체계적으로 관리하는 방법론이다.6 일반적으로 다음 6단계로 구성된다.6

1. 계획 (Planning): 프로젝트의 목표, 예산, 일정, 리소스를 정의한다.6 이해관계자와의 협의를 통해 요구사항을 명확히 파악하는 가장 중요한 출발점이다.6
2. 설계 (Design): 계획 단계의 요구사항을 바탕으로 시스템 아키텍처, 데이터베이스, 사용자 인터페이스(UI) 등 소프트웨어의 구조와 기능을 구체화한다.6
3. 개발 (Development): 실제 코딩이 이루어지는 단계로, 설계 명세서에 따라 개발자들이 모듈을 개발한다.6 버전 관리 시스템(예: GitHub)과 협업 도구가 중요하다.6
4. 테스트 (Testing): 소프트웨어의 품질을 검증하고 오류를 검출한다.6 단위 테스트, 통합 테스트, 시스템 테스트 등을 통해 사용자 요구사항을 충족하는지 확인한다.6
5. 배포 (Deployment): 개발 및 테스트가 완료된 소프트웨어를 실제 사용자 환경에 설치하고 운영을 시작한다.6
6. 유지보수 (Maintenance): 배포 후 발생하는 버그 수정, 기능 업데이트, 성능 최적화 등을 통해 소프트웨어의 수명을 연장하고 사용자 만족도를 유지한다.6

3.2 각 단계별 발주자의 핵심 점검 및 승인 사항

SDLC는 기본적으로 개발사의 프로세스다.6 발주자가 이 과정의 ’관찰자’로 머무른다면, 2~5단계는 ’블랙박스’가 되어버린다. 이는 6단계(유지보수)에 이르러서야 “우리가 원한 결과물이 이게 아니다“라는 최악의 상황을 맞이하게 되는, 전형적인 실패 프로젝트의 수순이다.

이를 방지하기 위해, 발주자는 SDLC의 주요 단계가 종료될 때마다 ’승인 게이트(Approval Gate)’를 설정하고, 이를 계약서에 명확히 명시해야 한다.

• 1. ‘계획’ 완료 후: 개발사가 작성한 ‘요구사항 정의서’ 5 및 ‘RFP(제안요청서)’ 7의 최종본을 발주사가 검토하고 ’승인’한다. 이 승인된 문서는 7장에서 다룰 법적 분쟁의 기준이 된다.
• 2. ‘설계’ 완료 후: ’시스템 아키텍처 설계도’와 ’화면설계서(UI/UX)’를 반드시 승인해야 한다. 코딩이 시작된 후에 설계를 변경하는 것은 막대한 비용 증가 1를 유발한다.
• 3. ‘개발’ 완료 후: 개발사의 내부 ‘단위/통합 테스트 결과 보고서’ 5의 제출을 의무화해야 한다.
• 4. ‘테스트’ 단계 중: 발주자(또는 발주사가 지정한 현업 담당자)가 직접 참여하는 ’사용자 인수 테스트(UAT)’를 반드시 수행해야 한다. 이 과정에서 발견된 중대 결함(Critical Bug) 목록을 작성하고 개발사의 수정을 요구해야 한다.
• 5. ‘배포’ 직전: UAT에서 발견된 중대 결함이 모두 해결되었음을 ’승인’한 이후에만 배포를 허가한다.

이처럼 SDLC 전반에 걸쳐 발주자가 능동적으로 개입하고 각 단계를 승인해야만 4장에서 논의될 ‘범위 크리프(Scope Creep)’ 4와 1장에서 우려한 ’비용 증가’를 효과적으로 통제할 수 있다.

4. 프로젝트의 성패를 가르는 ‘요구사항 분석’

모든 소프트웨어 프로젝트의 실패는 결국 ‘요구사항 분석’ 단계의 실패로 귀결된다. 위탁 개발의 성공은 화려한 코딩이 아니라, ’무엇을 만들 것인가’에 대한 명확한 ’정의’에서 결정된다.

4.1 명확한 요구사항 정의(RFP)의 중요성

요구사항 분석이란 프로젝트의 성공을 위해 이해관계자들의 요구와 기대를 식별, 문서화, 분석, 우선순위 지정하는 체계적인 활동이다.4 이 활동의 목적은 프로젝트의 ‘범위(Scope)’ 4를 명확히 확정하고, 개발자와 발주자 간의 의견을 조율하는 것이다.4

이때 사용되는 공식 문서가 ‘제안요청서(RFP, Request For Proposal)’ 7이며, 이를 더 구체화한 것이 ‘사용자 요구사항 정의서’, ‘유스케이스 명세서’ 등이다.5 명확한 요구사항 분석은 프로젝트의 비전과 로드맵을 제시하며 4, 개발 후반에 발생할 수 있는 치명적인 오해를 방지한다.4

4.2 요구사항 분석의 주체 및 일반적인 실패 요인

요구사항 분석은 개발사의 단독 업무가 아니다. 이는 프로젝트 관리자(PM), 제품 소유자(PO), 고객(발주사), 소프트웨어 엔지니어, QA 전문가 등 다양한 핵심 이해관계자가 참여하는 ’협업’이다.4

이 과정이 실패하는 주된 요인은 다음과 같다.

• 이해관계자 간의 명확성 부족: 발주사(이해관계자) 스스로가 소프트웨어에서 무엇을 원하는지 명확하게 알지 못하거나, 알고 있더라도 이를 일관되고 정확하게 표현하는 데 어려움을 겪는다.4 이러한 ’모호성’은 ’범위 크리프’와 ‘누락된 기능’ 문제를 야기한다.4
• 요구사항의 동적 특성: 시장 조건이나 사용자 우선순위의 변화로 인해 초기에 수집된 요구사항이 프로젝트 도중에 변경될 수 있다.4
• 요구사항의 상충되는 특성: 서로 다른 이해관계자 간의 요구사항이 충돌할 수 있다. 예를 들어, 강력한 ’보안’은 ‘성능’ 저하를 유발하는 상충 관계(Trade-off)에 있다.4

4.3 ‘내부 정치’ 문제 해결의 중요성

요구사항 분석 단계에서 가장 치명적이지만 간과되는 위험 요소는 발주사 ’내부의 정치(Internal Politics)’다.4 이는 서로 다른 기술을 가진, 혹은 서로 다른 부서의 팀원들이 ’자신의 역할을 더 강조하는 방식’으로, 즉 자 부서에 유리하게끔 프로젝트 요구사항이 설정되기를 원하는 경향을 의미한다.4

이러한 내부 정치는 ‘편향되지 않고 아젠다 없는’ 분석 프로세스 4를 근본적으로 방해한다. 예를 들어, A부서는 X기능을, B부서는 Y기능을 최우선으로 고집한다. 발주사의 PM(혹은 대표)이 이를 조율하지 못하고, 상충되는 요구사항 4을 그대로 개발사에 전달하며 “알아서 잘 해달라“고 요청하는 경우가 발생한다.

이때 개발사는 정치적 희생양이 된다. 둘 중 하나를 선택하면 선택받지 못한 부서의 저항에 부딪히고, 둘 다 어설프게 구현하면 ‘범위 크리프’ 4가 발생하여 프로젝트는 산으로 간다. 결국 프로젝트가 실패하면 A, B부서는 “개발사의 역량이 부족하다“고 비난하며, 내부의 정치적 조율 실패라는 ’본질’을 외부 개발사의 기술력 부족이라는 ’현상’으로 전가한다.

이는 1.3절에서 언급된 ’분쟁’과 ‘비용 증가’ 1로 가는 직행 열차다. 따라서, 발주사의 PM은 요구사항 분석 단계 4에서 내부 이해관계자들의 상충되는 요구를 반드시 조율해야 한다. ’하나의 목소리’로 우선순위를 명확히 결정하여 RFP 7를 작성하는 것은 개발사의 의무가 아닌, 발주사의 가장 중요한 책무다.

5. 최적의 파트너(개발사) 선정 및 평가

위탁 개발은 ’누구’와 함께하느냐에 따라 결과가 극명하게 달라진다. ‘최저가’ 업체가 아닌, ’최적가’의 ’전략적 파트너’를 찾는 객관적인 방법론이 필요하다.

5.1 개발사 선정 체크리스트

잠재적 파트너를 평가할 때는 다음 핵심 요소들을 반드시 검증해야 한다.8

• 과거 프로젝트(포트폴리오) 평가: 단순한 결과물 목록이 아닌, ’성공 사례’와 ’사례 연구(Case Study)’를 요구해야 한다.8 이를 통해 해당 업체가 과거에 유사한 문제를 어떻게 해결했는지, 다양한 산업과 기술 수요에 대한 적응력(다재다능함)을 갖추었는지 검증한다.8
• 기술 전문성 및 품질 보증(QA): 우리 프로젝트에 사용할 구체적인 ‘기술 스택(Technology Stack)’ 9을 확인하고, 개발사의 표준 ’품질 보증(QA) 관행’을 상세히 질문해야 한다.8
• 의사소통 및 프로젝트 관리: 프로젝트 관리에 사용할 ‘협업 도구’ 6와 방법론(예: 애자일, 폭포수)을 확인해야 한다. 또한, 의사소통 창구가 누구인지(CEO, CTO, 또는 PM) 명확히 하고, 정기적인 보고 체계를 수립해야 한다.8
• 지적 재산권(IP) 취급: 7장에서 상세히 다룰 지적 재산권 귀속 조항 10에 대한 개발사의 표준 입장을 사전에 확인해야 한다.8

5.2 정보 비대칭성 극복: 다수 견적 비교

개발사와 발주사 간에는 심각한 ’정보 비대칭성’이 존재한다.11 발주사는 개발사가 요구하는 비용이 적정한지 판단하기 어렵다. 이러한 비대칭성으로 인한 불필요한 비용 지출 위험을 줄이기 위해 11, 최소 3~5곳의 개발 회사에 견적을 요청하여 견적 범위를 파악하는 과정은 선택이 아닌 필수다.12

하지만 다수의 견적을 비교하는 목적은 단순히 가장 싼 곳을 찾기 위함이 아니다. 견적서 간의 ’편차(Variance)’는 발주사가 작성한 ’RFP의 품질’을 측정하는 리트머스 시험지다.

가령, 5개 업체에 견적을 요청했는데 12 견적이 1억, 1.2억, 1.1억, 1.3억, 1.1억으로 근소하게 나왔다고 가정하자. 이는 발주사의 RFP 7가 매우 명확하여 4 모든 개발사가 유사한 ‘범위’ 9를 산정했음을 의미한다. 이 경우에는 포트폴리오 8와 의사소통 방식 등을 비교하여 가장 신뢰 가는 업체를 선택하면 된다.

반면, 견적이 1억, 2.5억, 5천만 원, 3억, 1.5억으로 극심한 편차를 보인다면, 이는 ’가격’을 비교할 단계가 아니다. 이 현상은 발주사의 RFP가 4.2절에서 지적한 ‘명확성 부족’ 4 상태이며, 각 개발사가 프로젝트의 ’범위’를 제각기 다르게 해석했음을 의미한다. 이 상태에서 무턱대고 최저가(5천만 원)를 선택한다면, 해당 업체는 계약된 범위가 매우 좁다고 해석한 것이므로, 프로젝트 진행 중 발생하는 모든 추가 요구에 대해 1.3절의 ‘비용 증가’ 1 함정을 발동시킬 것이 100% 확실하다.

따라서, 견적 편차가 크다면 프로젝트를 즉시 중단하고 4장의 RFP와 요구사항 정의서 5부터 다시 작성해야 한다.

6. 위탁 개발 비용의 산정 및 통제

위탁 개발 비용은 ’결과’가 아니라 ’관리 대상’이다. 비용 구조를 이해하고 객관적인 산정 방식을 도입해야 ‘정보 비대칭성’ 11을 극복하고 예산을 통제할 수 있다.

6.1 견적에 영향을 미치는 핵심 요인

소프트웨어 개발 아웃소싱 비용은 맞춤 견적으로 산출되며, 다음과 같은 복합적인 요인에 의해 결정된다.

• 일반적 요인:
• 프로젝트 범위 (Scope): 구현해야 할 기능의 양과 복잡도. 범위가 가장 결정적인 요인이다.9
• 기술 스택 (Tech Stack): 사용하는 프로그래밍 언어, 프레임워크, 데이터베이스의 종류.9
• 개발 기간 (Timeline): 프로젝트 일정이 짧을수록 더 많은 인력이 투입되어야 하므로 비용이 상승한다.9
• 인력 구성 (Team): 투입되는 개발자의 경력 수준(초급, 중급, 고급)과 인원수.9
• 애플리케이션 특화 요인 (앱 개발 기준):
• 앱의 종류, 복잡성 및 기능: 4~5개 화면의 기본 앱과 대량 데이터 처리가 필요한 소셜 네트워크 앱, 또는 결제 모듈이 포함된 전자상거래 앱은 비용 차이가 막대하다.13
• UX/UI 디자인: 단순한 기본 디자인을 넘어, 독특하고 매력적인 고품질의 UX/UI 디자인을 요구할수록 많은 시간과 노력이 투입되어 비용이 상승한다.13
• 기술 및 플랫폼: iOS와 Android 각각을 따로 개발하는 ’네이티브 앱’은 하나의 코드로 양쪽을 지원하는 ‘하이브리드’ 또는 ‘크로스플랫폼’ 앱보다 일반적으로 높은 성능을 제공하지만, 개발 및 유지보수 비용이 더 높다.13

6.2 객관적 비용 산정 기법: 기능점수(Function Point) 방식

발주사 입장에서 가장 취약한 견적 방식은 ‘M/M(Man-Month, 월 투입 인력)’ 기반 견적이다. 개발사가 “이 프로젝트는 10 M/M가 필요합니다“라고 할 때, 발주사는 그 근거를 검증할 방법이 없다.

이러한 모호함과 ‘정보 비대칭성’ 11을 해소하는 가장 강력한 무기가 바로 ‘기능점수(FP, Function Point)’ 산정 방식이다.14 이는 소프트웨어가 사용자에게 제공하는 ’기능’을 식별하고 정량화하여 비용을 산정하는 국제 표준(IFPUG CPM) 기법이다.15

• 구성 요소: FP는 크게 2가지 유형, 5가지 기능으로 구성된다.14
• 데이터 기능: 내부논리파일(ILF, 예: 고객 DB, 사원 DB), 외부연계파일(EIF, 예: 타사 외환 DB 연동).15
• 트랜잭션 기능: 외부입력(EI, 예: 회원가입 기능), 외부출력(EO, 예: 월간 리포트 출력), 외부조회(EQ, 예: DB 데이터 단순 조회).16
• 산정 절차: 각 기능(예: ‘고객 DB’)이 얼마나 복잡한지(데이터 요소 유형(DET)과 참조된 파일(RET) 기준) ‘낮음’, ‘보통’, ’높음’으로 식별하고 16, 이를 점수화하여 합산한다.15
• 활용: 산정된 총 기능 점수(FP)를 프로그래밍 언어별 LOC(코드 라인)와 매핑하거나 15 표준 단가를 곱하여 전체 비용을 객관적으로 추정한다.

기능점수(FP) 방식은 단순한 ’견적 도구’가 아니다. 이는 발주사와 개발사 간의 ’범위 확정 도구’다. 발주사가 FP 기반 견적을 요구하면, 개발사는 M/M라는 ‘투입’ 기반의 모호한 견적이 아닌, “고객 DB(ILF) - 보통”, “사원 DB(ILF) - 보통” 15, “로그인 기능(EI) - 낮음”, “매출 조회(EQ) - 보통” 17과 같은 구체적인 ’기능 목록’을 제출해야 한다.

발주사는 이 ’기능 목록’을 보며 4.2절의 ‘누락된 기능’ 4이나 불필요한 기능을 사전에 확인할 수 있다. 즉, FP는 4장(요구사항 분석)의 결과를 정량화하고, 7장(하자보수)에서 발생할 분쟁을 예방하는 가장 핵심적인 ’범위 확정 문서’로 기능한다.

7. 법적 분쟁 예방을 위한 계약서 핵심 조항

“신뢰는 중요하지만, 계약은 필수다.” 위탁 개발 프로젝트의 성공적인 마무리는 ’신뢰’가 아니라 ’명확한 계약서’에서 나온다. 프로젝트 시작 전, 모든 잠재적 법적 쟁점을 문서화하고 상호 합의해야 한다.

7.1 비밀유지계약(NDA): 무엇을, 언제까지, 어떻게

프로젝트 논의를 시작하는 단계에서부터 ’비밀유지계약(NDA, Non-Disclosure Agreement)’을 체결해야 한다.

• 비밀정보의 범위: 의사결정에 ’충분한 범위’의 정보가 제공되어야 하지만, 범위를 과도하게 한정하면 실무 협상에 차질이 생긴다.18 핵심은 “Confidential“과 같은 비밀 표식이 없는 문서나 구두로 전달된 정보 18를 어떻게 취급할지 명시하는 것이다. (예: “구두 정보는 30일 내 문서화하여 비밀로 지정한다.”)
• 사용권: 제공된 비밀정보의 사용 범위, 기간, 방법, 그리고 ‘사용자’(열람 가능 인력)의 범위를 명시적으로 규정해야 한다.18
• 비밀유지 기간: 통상 5년, 7년, 10년 등으로 설정하거나, 핵심 영업비밀에 대해서는 ’무제한’으로 설정할 수 있다.18
• 계약 종료 후 처리: 계약이 종료된 후에도 비밀유지 의무는 계속될 수 있다.19 따라서 계약 종료 시점에서의 ‘비밀정보의 반환 또는 파기’ 절차를 명확히 규정해야 한다.19 이 조항이 불명확하면, 계약이 종료된 파트너가 발주사의 비밀정보를 계속 보유하거나 무단으로 사용할 수 있는 심각한 위험이 존재한다.19

7.2 지적 재산권(IP) 귀속: ’대금 지급’이 ’소유권’을 의미하지 않는다

발주사가 가장 쉽게 빠지는 함정은 “개발 비용을 전액 지불했으니, 결과물의 소유권(IP)은 당연히 우리 것“이라고 생각하는 것이다. 이는 사실이 아니다.

• 현실: 저작권법상 ‘저작자’(최초로 저작물을 창작한 자, 즉 개발사) 20와 ‘저작권자’(현재 저작권을 가진 자) 20는 분리될 수 있다. 별도의 양도 조항이 없다면, 비용을 지불했더라도 ’저작자’인 개발사에게 저작권이 남고, 발주사는 ’사용권’만 갖게 될 수 있다.
• 계약 원칙: 국내 SW 표준 하도급 계약서는 지적재산권 소유를 ’당사자간 협의하여 결정’하도록 규정한다.10 이는 발주사의 적극적인 ’협상’이 필요함을 의미한다.
• 책임 소재: 만약 개발자가 개발 과정에서 제3자의 저작권(예: 유료 폰트, 라이브러리)을 무단 침해했다면, 계약서에 발주사가 책임을 진다고 명시했더라도 원칙적으로 ’개발자’가 형사 책임을 부담해야 한다.21

따라서 발주사는 계약서에 “본 프로젝트를 위해 개발된 모든 산출물(소스코드, 디자인, 기획 문서 포함)의 지적 재산권은 최종 검수 및 잔금 지급이 완료되는 시점에 ’발주사’에게 포괄적으로 양도된다“는 조항을 반드시 삽입해야 한다.

이때, 많은 개발사가 개발 효율을 위해 자체적으로 보유한 ’라이브러리’나 ’모듈’을 재사용한다. 이 경우 “결과물 전체 IP는 양도하지만, 우리가 원래 보유한 모듈의 IP는 우리 소유“라고 주장할 수 있으며 이는 합리적인 요구다. 이 경우, 해당 모듈을 제외한 나머지 모든 산출물의 IP를 확보하고, 해당 모듈에 대해서는 발주사가 ‘영구적이고 로열티 없는 사용권’ 혹은 ‘개작권’ 10을 갖도록 협의해야 한다.

7.3 하자보수와 유지보수: 무상과 유상의 명확한 구분

프로젝트 완료 후 가장 빈번하게 발생하는 분쟁은 ’하자보수’와 ’유지보수’의 경계에서 발생한다. 공공 분야조차 유지보수를 ’무상 서비스’로 여기는 인식이 존재하여 SW 제값 받기에 걸림돌이 되기도 한다.22

• 하자보수 (Warranty): ’계약된 작업 범위 내’에서 발생한 오류나 버그 등을 수정하는 작업이다.23 이는 개발사가 제공하는 일종의 ’무상 A/S 서비스’이며, 대체로 1개월 정도의 무상 기간을 제공한다.23
• 유지보수 (Maintenance): 서비스의 안정적 유지를 위한 ‘지속적인 관리’(예: 서버 모니터링)와, ‘디자인 변경’ 또는 ’기능 추가’와 같은 ’추가 개발’을 의미한다.23 이는 명백히 ‘유상’ 계약이다.

분쟁의 핵심은 “이것이 ’하자(버그)’인가, 아니면 ’추가 기능’인가“에 대한 해석 차이다. 발주사는 “이거 안되네요, 버그니 고쳐주세요”(하자보수)라고 요구하고, 개발사는 “그것은 원래 계약된 기능에 없던 겁니다, 추가 개발비를 주세요”(유지보수)라고 맞선다.23

이 분쟁을 해결할 유일한 기준 문서는 4장의 ‘요구사항 정의서’ 5와 6장의 ‘기능점수(FP) 기능 목록’ 14이다.

따라서 계약서에는 “하자의 정의는 ‘요구사항 정의서’ 및 ’기능 목록’에 명시된 기능이 정상적으로 작동하지 않는 경우로 한정한다“고 명확히 명시해야 한다. 이 조항이 없다면, 발주사의 모든 ’개선 요청’이 ’하자’로 둔갑하여 22이 우려하는 ’유지보수의 무상 서비스화’가 발생하고, 개발사와의 파트너십은 결국 파탄에 이르게 된다.

8. [지역 심층 분석] 전남·나주·광주 소재 IT 자원 및 활용 전략

본 보고서는 전남, 나주, 광주 지역에 기반을 둔 중소기업이 즉시 활용할 수 있는 현지 IT 생태계 자원과 정부 지원 사업을 분석하고, 이를 결합한 구체적인 위탁 개발 실행 전략을 제안한다.

8.1 현지 개발 기업 현황: 파트너 탐색

파트너 탐색 8은 정보 비대칭성 11으로 인해 가장 어려운 과정이다. 하지만 전남·나주·광주 지역은 ‘인공지능 중심도시’ 24 비전 하에 강력한 IT/SW 생태계가 구축되고 있어, 검증된 현지 파트너를 탐색하기에 유리하다.

현지 기업 목록은 단순한 ’연락처’가 아니라 ’생태계 지도’다. 이 지도를 활용하여 지자체나 공공기관에 의해 1차 검증된 기업을 파트너 후보로 우선 고려하는 것이, 개별 기업이 포트폴리오를 검토하는 것보다 훨씬 신뢰도 높은 ‘필터’ 역할을 한다.

예를 들어, 광주시가 업무 협약을 맺고 유치한 AI 및 SW 개발 기업 24이나, 나주시의 ’스타기업’으로 선정된 27 기술 유망 기업들은 이미 일정 수준의 기술력과 사업성을 검증받은 후보군이다.

다음 <표 1>은 전남·나주·광주 지역에서 활동 중인 주요 IT/SW 개발 기업 목록이다.

<표 1> 전남·나주·광주 주요 IT/SW 개발 기업 리스트 및 전문 분야

(주): 위 목록은 수집된 자료24를 기반으로 하며, 지역 내 모든 기업을 포함하지 않음)

8.2 활용 가능한 정부 지원 사업: 개발 자금 확보

전남, 나주, 광주 지역 중소기업은 위탁 개발에 필요한 자금 및 컨설팅을 지원받을 수 있는 다양한 정부 지원 사업을 활용할 수 있다. 이는 단순한 비용 절감을 넘어, 프로젝트의 질을 높이는 중요한 전략적 도구다.

<표 2> 2024-2025년 기준 중소기업 대상 IT/SW 관련 주요 정부 지원 사업 요약

(주): 위 표는 2024-2025년 기준 공고27를 요약한 것이며, 실제 지원 시점에는 최신 공고문을 반드시 확인해야 함)

8.3 [전략 제안] 지역 자원을 활용한 ‘바우처 스태킹(Voucher Stacking)’

앞서 8.2에서 나열된 정부 지원 사업들은 단순한 ‘비용 절감’ 수단이 아니다. 이는 1장에서 7장까지 논의된 위탁 개발의 핵심 위험(불명확한 요구사항, 부적절한 파트너 선정, 품질 실패, 법적 분쟁)을 ‘구조적으로’ 해결할 수 있는 강력한 전략적 도구다.

전남/나주/광주 소재 중소기업은 이 지원 사업들을 개별적으로 활용하는 것을 넘어, 다음과 같이 ‘바우처 스태킹(Voucher Stacking)’ 전략을 구사하여 위탁 개발의 위험을 3중으로 분산시켜야 한다.

• 1단계 (기획 및 RFP 작성): ‘중소기업 혁신 바우처’ 활용
• 전략: ‘중소기업 혁신 바우처’ 34의 ‘컨설팅’ 분야를 신청한다.
• 실행: 이 바우처를 활용하여 전문 IT 컨설턴트를 고용, 4장에서 강조한 ‘요구사항 분석’ 4 및 ‘RFP 작성’ 7을 수행한다.
• 기대 효과: 발주사의 ‘명확성 부족’ 4과 ‘내부 정치’ 4 문제를 외부 전문가의 객관적 시각으로 해결한다. 이는 5.2절의 ’견적 편차’를 줄이고 7.3절의 ‘하자보수’ 분쟁을 원천 차단하는 가장 중요한 첫걸음이다.
• 2단계 (선택적 전문 위탁): ‘데이터 바우처’ 활용
• 전략: 만약 개발할 소프트웨어에 AI, 빅데이터 분석 기능이 포함된다면, ‘데이터 바우처’ 32를 신청한다.
• 실행: 이 바우처를 통해 8.1의 <표 1>에 명시된 광주/나주의 전문 AI 기업(예: 솔트룩스, 딥엑스 등) 24에 해당 기능만 ‘선택적 아웃소싱’ 2을 맡긴다.
• 기대 효과: 2.2절의 ‘선택적 위탁’ 전략을 정부 지원금으로 실행하여, 최고 수준의 ‘전문성’ 1을 확보함과 동시에 메인 개발사와의 ‘기능 통합’ 2 문제에만 집중할 수 있게 된다.
• 3단계 (품질 보증 및 테스트): ‘SW품질 역량강화 지원’ 활용
• 전략: ‘전남 SW품질 역량강화 지원’ 38 사업을 신청한다.
• 실행: 개발사의 자체 테스트 6와는 별개로, 전남정보문화산업진흥원과 같은 제3의 공공기관을 통해 개발 중인 소프트웨어의 ‘품질 컨설팅’ 및 ’테스트’를 지원받는다.
• 기대 효과: 발주사가 직접 수행하기 어려운 전문적인 ‘품질 관리’ 3 위험을 해소한다. 이는 3.2절의 ’사용자 인수 테스트(UAT)’를 보완하는 강력한 3자 검증 장치로 기능한다.

이 ‘바우처 스태킹’ 전략은 발주사의 현금 지출을 최소화할 뿐만 아니라, (1)전문가에 의한 RFP 작성, (2)최고 전문가의 선택적 활용, (3)제3자 기관의 품질 검증이라는 3중의 안전장치를 통해, 소프트웨어 위탁 개발의 성공률을 극적으로 높이는 최적의 실행 방안이다.

9. 결론: 전략적 파트너십으로서의 위탁 개발

소프트웨어 위탁 개발은 위험하지만 피할 수 없는 현대 비즈니스의 필수 전략이다. 본 보고서에서 분석한 바와 같이, 프로젝트의 실패는 대부분 ’기술’이 아닌 ’관리’의 영역, 특히 ‘요구사항의 모호함’ 4, ‘잘못된 파트너 선정’ 11, 그리고 ‘불명확한 계약’ 23에서 비롯된다.

성공적인 위탁 개발을 위해서는 발주사가 ’최저가’라는 단기적 유혹에서 벗어나, 명확한 요구사항 정의(RFP)와 객관적인 비용 산정(FP) 14을 통해 ’전략적 파트너’를 발굴해야 한다. 또한, SDLC 전 과정에 ‘승인 게이트’ 6를 설정하여 능동적으로 개입하고, IP 귀속 10 및 하자보수의 범위 23를 명확히 하여 법적 위험을 통제해야 한다.

특히 전남·나주·광주 지역의 기업들은 ‘인공지능 중심도시’ 24라는 강력한 지역 생태계와 다양한 정부 지원 사업 32을 활용할 수 있는 독보적인 이점을 지니고 있다. 본 보고서가 제안한 ‘바우처 스태킹’ 전략을 통해, 지역 중소기업은 위탁 개발의 고질적인 위험을 구조적으로 해소하고 비즈니스 혁신을 성공적으로 달성해야 한다. 위탁 개발의 성공은 비용 지불이 끝이 아니라, 명확한 관리와 지속적인 파트너십을 통해 완성된다.

10. 참고 자료

1. IT 아웃소싱 - IT 위키, https://itwiki.kr/w/IT_%EC%95%84%EC%9B%83%EC%86%8C%EC%8B%B1
2. 아웃소싱(Outsourcing) - IT RED OCEAN 에서 살아 남기(일흔까지만), https://middleware.tistory.com/entry/%EC%95%84%EC%9B%83%EC%86%8C%EC%8B%B1Outsourcing
3. 소프트웨어 개발 아웃소싱에 대한 최고의 가이드 - Scopic Software, https://scopicsoftware.com/ko/blog/software-development-outsourcing/
4. 요구 사항 분석: 올바른 수행을 위한 핵심 단계 및 기법 - ClickUp, https://clickup.com/ko/blog/138879/requirements-analysis
5. 요구사항 정의서 - velog, https://velog.io/@angel_eugnen/%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD-%EC%A0%95%EC%9D%98%EC%84%9C
6. 소프트웨어 개발 수명 주기(SDLC)란 무엇인가요? - Hitek Software, https://hitek.com.vn/ko/blog-ko/software-development-life-cycle/
7. 영향력 있는 RFP를 작성하는 방법: 팁, 템플릿 및 실제 RFP 예시 - ClickUp, https://clickup.com/ko/blog/212320/rfp-examples
8. 소프트웨어 개발 아웃소싱 파트너에게 물어봐야 할 8가지 주요 질문 - The Codest, https://thecodest.co/ko/blog/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C-outsourcing-%ED%8C%8C%ED%8A%B8%EB%84%88%EC%97%90%EA%B2%8C-%EB%AC%BC%EC%96%B4%EB%B4%90%EC%95%BC-%ED%95%A0-8%EA%B0%80%EC%A7%80-%EC%A3%BC/
9. IT 외주 성공률 극대화를 위한 업체 비교 분석 총정리 - TreeSoop, https://treesoop.com/%EC%99%B8%EC%A3%BC-%EB%B0%A9%EB%B2%95/it-%EC%99%B8%EC%A3%BC-%EC%84%B1%EA%B3%B5%EB%A5%A0-%EA%B7%B9%EB%8C%80%ED%99%94%EB%A5%BC-%EC%9C%84%ED%95%9C-%EC%97%85%EC%B2%B4-%EB%B9%84%EA%B5%90-%EB%B6%84%EC%84%9D-%EC%B4%9D%EC%A0%95%EB%A6%AC/
10. 슬라이드 1, https://www.moef.go.kr/com/cmm/fms/FileDown.do?atchFileId=ATCH_OLD_00004003620&fileSn=412558
11. 소프트웨어 외주 개발, 업체 선정부터 계약서 작성까지 10 단계 가이드 - 리트머스, https://litmers.com/blog/%EC%99%B8%EC%A3%BC%EA%B0%9C%EB%B0%9C-%EC%8B%A4%ED%8C%A8%EB%A5%BC-%EB%B6%80%EB%A5%B4%EB%8A%94-%ED%95%A8%EC%A0%95-%EC%B4%9D%EC%A0%95%EB%A6%AC
12. 아웃소싱 전문가가 밝히는: 2 소프트웨어 개발 견적, 왜 천차만별일까? - 요즘IT - 위시켓, https://yozm.wishket.com/magazine/detail/1731/
13. 앱 개발 아웃소싱 비용에 미치는 영향 - 앱 개발 비용 최적화 방법, https://hblabgroup.com/ko/app-development-outsourcing-cost/
14. 기능 점수 (FP, Function Point) - velog, https://velog.io/@corone_hi/%EA%B8%B0%EB%8A%A5-%EC%A0%90%EC%88%98-FP-Fuction-Point
15. [CS][소프트웨어공학] SW 기능 산정 (기능점수, 간이법) - y-seo의 딩코 기록들, https://y-seo.tistory.com/entry/CS%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%EA%B3%B5%ED%95%99-Chapter03-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EB%B9%84%EC%9A%A9
16. 기능점수(Function Point) 기본 개념과 산정방식 - MediaNavi 미디어나비 Blog, https://blog.medianavi.kr/2023-06-02-FP/
17. SW 대가 산정 방법 중 기능점수 산정법(FP 산정), https://sisw.com/entry/SW-%EB%8C%80%EA%B0%80-%EC%82%B0%EC%A0%95-%EB%B0%A9%EB%B2%95-%EC%A4%91-%EA%B8%B0%EB%8A%A5%EC%A0%90%EC%88%98-%EC%82%B0%EC%A0%95%EB%B2%95FP-%EC%82%B0%EC%A0%95
18. [NDA 쟁점] 비밀유지계약 NDA, CDA 관련 실무적 쟁점 및 대응방안, https://tradesecret.tistory.com/623
19. 소프트웨어 기업의 해외 진출을 위한 영문 NDA(비밀 … - 법무법인 비트, https://www.veatlaw.kr/main/board_detail/1139
20. 2005 SW지적재산권 - 상 담 사 례 집 - 한국저작권위원회, https://www.copyright.or.kr/information-materials/publication/research-report/download.do?brdctsno=10426&brdctsfileno=4102
21. 소프트웨어 개발계약에서 저작권의 귀속과 책임소재 - 네플라, https://www.nepla.ai/wiki/%EC%A7%80%EC%8B%9D%EC%9E%AC%EC%82%B0/%EC%A0%80%EC%9E%91%EA%B6%8C/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C%EA%B3%84%EC%95%BD%EC%97%90%EC%84%9C-%EC%A0%80%EC%9E%91%EA%B6%8C%EC%9D%98-%EA%B7%80%EC%86%8D%EA%B3%BC-%EC%B1%85%EC%9E%84%EC%86%8C%EC%9E%AC-e3j915vlrn2q
22. [전문가기고]공공SW사업 유지보수 정책 개선에 대한 제안 - 소프트웨어정책연구소, https://spri.kr/post/22840
23. 하자보수와 유지보수의 차이점 / 하자보수와 유지보수 / 하자보수 유지보수 가격 - 디펙트럼, https://dpectrum.app/blog/24
24. 광주시 - 광주광역시청, https://www.gwangju.go.kr/fileDownload.do?fileSe=BB&fileKey=BD_0000000027%7C5153&fileSn=2&boardId=BD_0000000027&seq=5153
25. ‘인공지능 대표도시’ 광주시, AI기업 2개 회사와 협약 - 프레시안, https://www.pressian.com/pages/articles/2025050817525933655
26. ‘올해만 32개’ 유망 인공지능(AI) 기업 광주행, https://smartcity.go.kr/2024/05/27/%EC%98%AC%ED%95%B4%EB%A7%8C-32%EA%B0%9C-%EC%9C%A0%EB%A7%9D-%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5ai-%EA%B8%B0%EC%97%85-%EA%B4%91%EC%A3%BC%ED%96%89/
27. ISO 인증 정부지원 사업 홍보. > 문의하기 | 그누보드5, http://dient.co.kr/gnuboard5/bbs/board.php?bo_table=question&wr_id=2&sst=wr_datetime&sod=desc&sop=and&page=1
28. ANSOLUTION l 주식회사 앤솔루션, https://www.ansol.co.kr/
29. (주)엔텔스나주지점 2025년 기업정보 | 기업리뷰 1건, 연봉정보 0건, 면접후기 0건, 복지정보 0건, 채용공고 0건, https://www.jobplanet.co.kr/companies/469652/landing/%EC%97%94%ED%85%94%EC%8A%A4%EB%82%98%EC%A3%BC%EC%A7%80%EC%A0%90
30. (주)바이텍정보통신 나주지사 2025년 기업정보 | 기업리뷰 2건, 연봉정보 0건, 면접후기 1건, 복지정보 0건, 채용공고 0건, https://www.jobplanet.co.kr/companies/455248/landing/%EB%B0%94%EC%9D%B4%ED%85%8D%EC%A0%95%EB%B3%B4%ED%86%B5%EC%8B%A0-%EB%82%98%EC%A3%BC%EC%A7%80%EC%82%AC
31. 전남나주 강소특구, http://najuinnopolis.com/49
32. 전남도, 데이터바우처 지원사업 참여 독려 - 영암열린신문, https://m.openmedia.co.kr/2906584738
33. 소식 및 알림 - 한국데이터산업협회, http://www.kodia.kr/bbs/notice/1194
34. [전남] 2025년 2차 중소기업 혁신바우처 사업 지원계획 공고 - 기업마당, https://www.bizinfo.go.kr/web/lay1/bbs/S1T122C128/AS/74/view.do?pblancId=PBLN_000000000104912
35. 2022년도 나주시 스타기업 모집 공고 | 지원사업정보 - 이드로경영파트너스, https://edro.co.kr/board.es?mid=a10101000000&bid=0002&act=view&list_no=7299&nPage=65
36. 년도 나주시 스타기업 모집 공고 2025, https://grant-documents.thevc.kr/262681_202505081000244389.pdf
37. 기업마당>정책정보>지원사업 공고, https://www.bizinfo.go.kr/web/lay1/bbs/S1T122C128/AS/74/view.do?pblancId=PBLN_000000000110802
38. [전남] 2025년 디지털 제품ㆍ서비스 컨설팅 및 테스팅 공고 - 기업마당>정책정보>지원사업 공고, https://www.bizinfo.go.kr/web/lay1/bbs/S1T122C128/AS/74/view.do?pblancId=PBLN_000000000107561
39. [전남] 2025년 지역디지털기초체력 지원사업 지역선도기업사업화 지원사업 모집 공고, https://www.bizinfo.go.kr/web/lay1/bbs/S1T122C128/AS/74/view.do?pblancId=PBLN_000000000104084
40. [전남] 기술형 창업 생태계 조성사업 창업연계 SW라이센싱 비용 지원사업 대상자(기업) 모집공고 - 기업마당, https://www.bizinfo.go.kr/web/lay1/bbs/S1T122C128/AS/74/view.do?pblancId=PBLN_000000000013825